1. Field of the Invention
This invention relates to computers and is particularly concerned with the performance and reliability of computer systems including a standard CPU, such as the Motorola MC 68000, INTEL iAPX 286, etc., and the memory accessed from such CPUs. The invention allows machine instructions of a standard CPU to be utilized in a much more efficient and reliable way than is otherwise possible.
There now follows a general description of the technical background to the invention followed by a detailed description of some specific embodiments of the invention with references to the accompanying drawings.
2. Background of the Invention
FIG. 1 shows a simplified block diagram of a computing system. This system is not the subject of the invention, but introduced in order to be able to explain the background to, and the salient points of, the invention. The main parts of the computing system in FIG. 1 are the Central Processing Unit (CPU) 10, the Memory (M) 40, and the Input/Output Interface (IO) 60 to the external world. The CPU contains a Control Logic function (CL) 12, which is not described in detail, and four registers; a Program Counter register (PC) 14, an Address Register (AR) 16, a Data Register (DR) 18 and an Instruction Register (IR) 20. The information stored in these registers can be read and written by CL 12. The memory (M) 40 contains N memory words (MW.sub.0, MW.sub.1, . . . MW.sub.N-1), and an Address Decoder (AD) 42, the input of which is connected to the Program Counter (PC) 14 and the Address Register (AR) 16 of the CPU 10. Each memory word contains a specific number of binary memory elements, each one of which may store either 0 to 1. All the memory words are connected to the Data Register (DR) 18 of the CPU 10, i.e. the contents of any memory word may be transferred to DR 18 and vice versa. The Control Logic (CL) 12 of the CPU has two control outlets, a Read Outlet (R) 22 and a Write Outlet (W) 24, which are connected to all the memory words in parallel. When CL 12 issue a Read command, the Address Decoder (AD) 42 selects the Memory Word, which corresponds to the contents of the Address Register (AR) 16 or the Program Counter (PC) 14, and the R Control Outlet 22 from CL 12 enables the transfer of information from the selected memory word into the Data Register (DR) 18 if the address is obtained from the Address Register (AR) 16, and into the Instruction Register (R) 20 if the address is obtained from the Program Counter (PC) 14. If a Write Command is issued, the W Control Outlet 24 from CL 12 enables the transfer of information from the Data Register (DR) 18 into the memory word addressed by the Address Register (AR) 16.
The information stored in the memory words can be used in two different ways, either as data or as control instructions.
When the information stored in a memory word is used as data, the separate binary memory elements are combined together to form a single value (V.sub.m) 70 according to the principle shown in FIG. 2a. This value can then be manipulated by the CL 12 in the desired manner, e.g. arithmetic operations, logic operations, etc. For a memory word MX.sub.x 72 containing m binary memory elements or bits, the total number of different data values represented by different combinations of the m bits, which can be stored in the memory word is 2.sup.m. These bit combinations may be used to represent values ranging from 0 to 2.sup.m -1 as illustrated by the example of the possible values for a 4-bit memory word in FIG. 2b. In special cases (e.g. binary coded decimal values) the value range may be further restricted. It is to be noted, that the manipulation of data values in CL 12 will give the correct result only as long as the result values do not exceed the number of bits, which can be manipulated and stored. In a system with 4-bit memory words and 4-bit control logic the addition 8+8 would give the result 0 instead of 16, because the representation of 16 in a four bit system would be 0. It is also to be noted that the information may be coded so that the most significant bit is used as a sign bit with, for instance, positive values denoted by the value 0 and negative values by the value 1. The value range of a four bit variable would, in this case be -8 to +7, i.e. still 16 values. Other Coding schemes are, of course, also possible.
Memory words used for data storage purposes are usually randomly accessed, i.e. no implicit relationship exists between the address of one data word and another data word. In order to access a data word, the address of the word has to be transferred into the Address Register (AR) 16. Thereafter the contents of the word can be read into the Data Register (DR) 18, or the contents of the Data Register (DR) 18 can be stored into the memory word. It is to be noted that it is possible to build explicit relationships between data words. One possibility is the sequential array, i.e. a number of consecutive memory words, which contains related information and which can be accessed by setting the Address Register 16 to, for instance, the first word in the array and then incrementing the Address Register 16 to access consecutive words in the array. Another possibility is the chaining of data elements, i.e. storing the address of one memory word, as information, in another memory word. In order to access such an indirectly addressed memory word, the information from the first word is first read into the Data Register (DR) 18, and then via CL 12 transferred to the Address Register (AR) 16.
A program consists of a number of sequentially executed Machine Instructions. It is therefore natural, that the memory words used to store the Machine Instructions of a program also follow one another sequentially. The sequential execution of Machine Instructions stored in consecutive memory words is the normal mode of operation and therefore built into the Control Logic of the CPU 10. In order to access memory words containing Control Instructions the Program Counter (PC) 14 is used to select the memory word to be read. The information is then transferred to the Instruction Register (IR) 20, where CL 12 can access and evaluate the instruction. Each time a Machine Instruction is read from the memory, the Program Counter 14 is automatically incremented so that control instructions are read in consecutive order.
When a Machine Instruction has been read into the Instruction Register 20 the Control Logic (CL) 12 first decodes the instruction. Depending on how the decoding is performed the bits of an instruction form bit groups, where each bit group has a separate meaning (and may even overlap each other in some cases). FIG. 3 illustrates a simplified example of instruction decoding in a memory word MW.sub.p 80, where it has been assumed, that instructions contain three bit groups, a Command Code group (CC) 82 and two Operand bit groups (OP1) 84 and (OP2) 86. The Command Code determines the actual instruction to be executed and the operands specific parameters of that execution. It is for instance possible to give a memory address as OP1 and a data value as OP2 with the command code of the instruction specifying writing into memory (Store Data =SD instruction). The Control Logic (CL) 12 will then perform the following activities:
Transfer OPI 84 into the AR register 16 of FIG. 1. PA0 Transfer OP2 86 into the DR register 18 of FIG. 1. PA0 Assert the W control signal 24 to the memory M 40, whereby the information in DR 18 will be written into the memory word addressed by AR 16. PA0 Increment the PC register 14 to prepare execution of the next instruction. PA0 Transfer OPI 84 into the PC 14 register, thereby preparing for execution of the next instruction at the specified memory word. PA0 * Permanent Data Area 150--A memory area containing data elements, which may be read by any program, but must not be written into by any program during normal operation. A permanent data area may be assigned the Read Only (RO) property by hardware means. PA0 * Semipermanent Data Area 152--A memory area containing data elements, which may be read by any program, but may only be written into by certain programs, provided that explicitly defined security and verification measures are undertaken. A semipermanent data area may be assigned a Conditional Read Only (CRO) property by hardware means. PA0 * Transient Data Area 154--A memory area containing data elements, which may be freely read and written by any program. A transient memory area has the basic Read/Write (RW) property. PA0 * Program Area 156--A memory area containing executable programs or programs with embedded permanent data elements. A program area may therefore be assigned the Execute Only (EO) or the Execute and Read (ER) property. PA0 (a) when writing into transient data 154 is intended, but the actual memory address points to a semipermanent data area 152, a permanent data area 150 or a program area 156. PA0 (b) when authorized writing into a semipermanent data area 152 is intended, but the actual address points to a permanent data area 150 or a program area 156. PA0 (c) when reading of data is intended, but the actual memory address indicates a program area with the Execute Only property. PA0 (d) when execution of a program is intended, but the actual memory address indicates an area which does not have an Execute property. PA0 DE1: HEADER is read-only string(8)="USER32XX", PA0 DE2: COUNTER1 is integer 0 to 300, PA0 DE3: COUNTER2 is integer -1000 to 1000, PA0 DE4: STATUS is array (0 to 4) of conditional-read-only WORD, PA0 DE5: OUTLINK is link, PA0 DE6: TIMER is array (0 to 4) of integer 0 to 15, PA0 DE7: CATEGORY is array (0 to 4) of read-only set (ON, OFF)=(ON', ON, OFF, OFF, ON') PA0 DE8: COUNTER3 is conditional-read-only integer 0 to 9, PA0 DE9: NUMBERING is integer 0 to 10000, PA0 DE10: CHECKSUM is read-only integer 0 to 10000, PA0 * The absolute address where the data element is located (or the start address of the first element of an array). PA0 * The length of the data element in number of bits. PA0 * Indication whether the data element is an array element or not. PA0 * The number of array elements if the data element is an array. PA0 * Auxiliary information not directly relevant for the described purpose and therefore not further itemized.
Another example is the case where OP1 18 gives a memory address and the command code specifies a `jump` (JP instruction). In this case the control logic performs the single activity:
The number of operands used in any particular instruction may vary with the instruction as already illustrated by the two examples above. Some instructions use no operands at all. Some instructions may even require three or four operands.
Gradually the general computer system structure in FIG. 4 has evolved, which structure is now taken for granted in practically all types of conventional computing systems. The hardware consists of the Central Processing Unit (CPU) 90 with its set of Machine Instructions (MI), the Memory (M) 100 and the interface to the external world (IO) 110. In FIG. 4 the Data Flow and Control Flow relationships are shown, where each such relationship assumes the existence of a hardware connection. The Memory (M) 100 is normally accessed by the CPU 90, but can also, if necessary, be accessed directly from the IO hardware 110 without the CPU 90 being involved. The software, which resides in the memory M 100, consists of the Application Programs (AP) 102, the Input/Output Interface Programs (IOP) 104, the Operating System (OS) 106 and the Data Base (DB) 108.
The Machine Instructions (MI) 92 consists of the set of instructions, which are executable within the CPU 90 and generally available for the design of any programs (OS 106, AP 102, IOP 104.
The Data Base (DB) 108 contains all of the data for the system, which data can be read and written by the CPU 90 under the control of the various programs.
The Interface Programs (IOP) 104 are a set of programs specifically designed to control the actual types of peripheral devices (IO) 110 used in the interworking with the external world. The Interface Programs are called either from the Master Scheduler (MS) 112 or from the Application Programs (AP) 102, and can themselves call Utility Subprograms.
The Application Programs (AP) 102 are a set of user specific programs, which have been designed to solve specific application problems (e.g. different types of computation). Application Programs are called from the Master Scheduler and may call Utility Subprograms and Interface Programs.
Finally, the Operating System is the application independent System Control Program, which contains two parts, the Master Scheduler (MS) 12, and the Utility Subprograms (US) 114. The Master Scheduler (MS) 112 is usually driven by means of Interrupt Signals (IS) 116, and controls the execution of all other programs in the entire system. The Utility Subprograms (US) 114 are a set of generally available subprograms, which have been developed to solve problems of a general nature, but which are too complex to be performed by means of single Machine Instructions. The Utility Subprograms can be called from any type of programs OS 106, AP 102 or IOP 104.
FIG. 5, wherein the same parts are given the same part numbers as in FIG. 4, shows a block diagram of the principal software structure, which is based on the hardware/software system structure in FIG. 4, and which is currently considered to be the basic software structure in conventional software technology. The software is split into two types of units, data and programs. The data of a system consist of individual data elements and structures (DE) 118 located in the Data Base (DB) 108 of the system. The programs consist of Operating System programs (OS) 106, Application Programs (AP) 102 and Input/Output Programs (IOP) 104. AP 102, IOP 104 and US 114 contain a set of programs (P), all of which are composed of Machine Instructions of the actual computer.
FIG. 6 shows an example of a typical layout of memory, which corresponds with the software structure in FIG. 5. Certain areas of the memory are dedicated to the Operating System with its programs, tables and other data areas, to which the user software have no access in principle. Other areas of the memory are dedicated to the exclusive storage of the Data
Base, within which areas some subareas are dedicated exclusively to a particular user, some exclusively to another user, some dedicated to the exclusive use of several particular users and some areas being used by any and all program (including Operating System, IOP, Utility Subprograms etc.). Still other areas of the memories are used for programs of any type, some of which again are dedicated exclusively to a single user and some which are common for several users up to, and including, all users (common subprograms and common data).
A system which is implemented according to the principles shown in FIG. 6 will experience a number of problems, which are more or less interrelated. One of these problems is the administration and management of the user software.
As illustrated by FIG. 6 each user has a number of program and data areas, which belong to him, and a number of program and data areas, which do not belong to him, but which he nevertheless may use or access. When a new user software unit is to introduced into an existing system, then space must be reserved for each of the areas which is exclusive for that software unit. Secondly it must be known whether any area used jointly with other software units is already in existence within the system. In that case that area needs to be linked to the rest of the areas accessible from that software unit. If no other software unit currently exists which needs the use of a jointly used area, then this area needs to be allocated before linking may be done. The reverse problem of course exists when a software unit is to be removed from a system, i.e. in this case the exclusive areas must be easily removed. However, any joint area may only be removed if no other user requiring this area exists.
Due to present technological limitations and the ever present requirement to be able to achieve higher performance with existing computers, one of the favored techniques for linking software areas together is by means of so-called `pointers`. Pointers are nothing more than absolute memory addresses stored as data in the memory itself and may, as such, be simply and efficiently processed by the computer and stored in the memory of the computer, both as fixed relationships in the programs and as variable relationships in the data areas. FIG. 7 illustrates a representative example of possible pointer relationships for a single user. It is assumed that the Master Scheduler of the Operating System holds a master pointer to any User Program (exemplified by UPP1 130 in FIG. 7). The User Programs then contain further pointers to subprograms and data as required. The complexity of the problem of introducing software for any user into the system (and removing it from the system if and when required) now becomes apparent. In a system of the type illustrated in FIG. 7 the only realistic way of solving the problem is by means of an Off-Line Support system, which keeps track of all absolute addresses in order to be able to generate the actual binary code to be stored as programs and data in the memory. This of course makes any run-time changes or modification of the software extremely difficult. Emergency procedures for this purpose (so called `patching` procedures) have been developed, but these cannot be considered to be satisfactory.
A second problem caused by the use of pointers is the reliability of the system. Correct operation of any software system postulates a) that all the pointers are correctly calculated and b) that they remain so. FIG. 8 shows an example of a user data structure in a memory pointers are used. This user data structure is implemented as two separate rows of memory words, the first row containing the three logical data elements Cl 132 located at memory address 35492, Pl 134 located at memory address 35493 and X 136 located at memory address 35494, and the second row containing the five logical data elements C2 138, C3 140, P2 142, P3 144 and Y 146 located at the memory addresses 48373, 48374, 48375, 48376 and 48377, respectively. Each of the data element is used for a particular purpose, which often is reflected in the logical name, which is associated with the data element, e.g. Cl 132, C2 138, and C3 140 for elements used as counters; pl 134, P2 142, and P3 144 for elements used as pointers, X 136 and Y 146 for general purpose data elements. In FIG. 8 the two disjoint memory areas are shown to be linked via the two pointers P1 134 and P2 142, where P1 contains the address to the first memory word of the second memory area (48373) 138 and P2 in turn contains the address to the first word of the first memory area (35492) 132. Assuming that an externally obtained pointer indicates one of the memory areas, then all of the memory words will be accessible by means of the suitable logic. This will be illustrated by means of the following example, where it is assumed that the following logic operations are to be performed in the indicated sequence:
______________________________________ C1: = C1 + 1 Increment counter C1 C2: = C2 + 1 Increment counter C2 C3: = C3 + 1 Increment counter C3 Y: = X Transfer the contents of X to Y ______________________________________
Assuming that the Address Register (AR) 16 in FIG. 1 has been set up to hold the address 35492 132 (=the External Pointer of FIG. 8) prior to the execution of the program, and that the program itself resides at some addresses A, A+1, A+2, etc. in the memory, then the logic operations may be performed by a sequence of machine instructions:
______________________________________ A ADD @AR,1 Increment C1 A+1 LD AR,@AR +1 Transfer P1 to AR A+2 ADD @AR,1 Increment C2 A+3 ADD @AR +1,1 Increment C3 A+4 LD AR,@AR +2 Transfer P2 to AR A+5 LD DR,@AR +2 Transfer X to DR A+6 LD AR,@AR +1 Transfer P1 to AR A+7 SD DR,@AR +4 Store DR in Y ______________________________________
The above program sequence is perfectly valid as long as the initial address given by the External Pointer (=35492) at the program entry point is correct. However, assume that the External Pointer is incorrectly pointing to the address 35493. The effect of this will be as follows:
(a) The instruction at address A, which was originally designed for the purpose of performing the operation C1 : =C1+1, will now actually add 1 to the contents of the memory word at address 35493. Hence it will not be performing the operation C1 : =C1 +1 at all, but instead be performing the equivalent of the operation P1:=P1+1, thereby making P1 contain the value 48374 instead of 48373.
(b) The instruction at address A+1 originally designed for the purpose of reading the pointer P1 134 prior to incrementing the counters C2 138 and C3 140 will now read the contents of the memory word at address 35494, i.e. it will perform the equivalent of reading and using the contents of the data element X 136 as a pointer.
(c) The instructions at addresses A+2 and A+3 originally designed for the purpose of performing the operations C2: =C2+1 and C3:=C3+1 will now perform the operations on the memory at the addresses indicated by the current contents of the data element X 136. Because the contents of X 136 varies with time, this means that two consecutive memory words at random will be incremented. In other words, random errors will be introduced into the system.
(d) The instruction sequence at addresses A+4 to A+7 designed for the purpose of performing the operation Y 146:=X 136 will now perform a transfer of information from a memory word outside the user area in FIG. 8 (i.e. at address 35495) to a randomly indicated memory word.
The above type of software error introduced by executing otherwise correct programs with faulty pointers is defined as cross purpose memory accessing, because a memory word used for a specific purpose may now inadvertently be used for a completely different purpose. One of the worst characteristics of a system where cross purpose memory accessing is possible is that a single error `breeds` new errors. The execution of the instruction sequence from A to A+7 above with the incorrect pointer value will for instance generate a total of 8 errors, five of which are inside the user area of FIG. 15, i.e. C1 132, C2 138 and C3 140 are left unincremented, the old value of Y 146 is not overwritten by the value of X 136 and the pointer P10 134 is erroneously incremented where it should not have been incremented. If now the same sequence of instructions is executed a second time, this time with the correct input pointer value, then the instructions at the addresses from A+1 to A+7 will generate new errors by virtue of the fact that P1 134 now contains a faulty value left by the previous faulty execution. In this case C2 138 will not be incremented where it should. The instruction sequence which should have incremented C2 138 will now increment C3 140, thus by random chance generating the correct result and thereby actually masking the error. The instruction sequence which should have incremented C3 140 will now increment P2 142, thus again generating a potential new `error breeder`. Finally, the instruction sequence by means of which the operation Y 146:=X 136 is realized will again generate an error outside the user area of FIG. 8.
It should be evident that any system where cross purpose memory accessing is potentially possible will work as long as no cross purpose memory accessing error exists within the system. However, it should be equally evident that if even a single cross purpose memory accessing error is introduced anywhere in the system, then correct operation of the system, both in parts and as a whole, can no longer be guaranteed. One of the consequences of this state of affairs is that if even one cross purpose memory accessing error is detected, then the probability approaches one that additional cross purpose memory accessing errors exist within the system. Hence the only practical means of restoring the system to a state where faultfree operation will be possible is to restart the entire system, i.e. to unconditionally interrupt the ongoing program execution, to reset all data areas to predefined values and thereafter to start program execution from a predefined restart point for the system as a whole.
One of the known methods for detecting cross purpose memory accessing errors once they have occurred is by means of so called `Audit Programs`. Audit programs are periodically or on demand executed programs, which postulate the existence of implicit or explicitly introduced redundancies in the software. The pointer P2 142 in FIG. 8 is one example of such an explicitly introduced redundancy. It is now possible to design an audit program which, given the External Pointer (=35492) as input data, will address the memory word containing P1 134 by adding 1 to the External Pointer, use the stored value of (the assumed) P1 134 as a new pointer, add 2 to this value, thereby (assumedly) addressing P2 142, reading (the assumed) P2 142 and comparing this value with the original External Pointer. If no cross purpose accessing error exists within the areas checked and controlled by this audit program, then the values will match as they do in FIG. 8. If a mismatch is indicated by an audit program, then the existence of at least one cross purpose memory accessing error is indicated. The system therefore will have to be restarted in order to clear the indicated error as well as any other existing but not detected cross purpose memory access error or any consequence thereof.
Cross purpose memory accessing errors may be caused by both software and hardware faults. It is therefore impossible to guard against cross purpose memory accessing errors purely by software means. One of the principles which has been used to reduce the cross purpose memory accessing error problem, is to establish separate memory areas which are then used for different purposes, the memory area being physically separated from each other by assigning each such area a characteristic set of properties, which are recognized by the hardware and therefore may be used for protection purposes.
FIG. 9 illustrates an example of such a separation of memory areas with the following four types of memory areas:
By introducing separate instructions (or parameters of the instructions) for reading and writing information from and into areas with different properties, it will now be possible to detect some of the cross purpose accessing errors when they actually occur instead of the after the fact, which is the only means possible for audit programs. For instance, it is possible to design a hardware protection mechanism to be triggered :
A number of different possibilities exist, whereby such a hardware protection mechanism may be realized. One possibility is the physical separation of areas into separately addressable memories. In this case the protection mechanism may simply utilize some of the address bits in combination with the required property as defined by the actual instruction (or a parameter thereof). Another possibility is the logical separation of the areas within the same memory by means of adjustable hardware registers, wherein the limits of each area may be defined. In this case the protection mechanism will decode the required property from the actual instruction (or a parameter) in order to define the set of limit registers to use, whereafter the actual address may be compared with the limit registers to ascertain that the address lies within the allowed limits. Still a third known method is the adding of control bits for each memory word in addition to the information bits, whereby the control bits indicate the actual property of the information to be stored within the memory word.
None of these methods give adequate protection, however, because all cross purpose memory accessing errors cannot be detected. If, for instance, writing of information to a transient data element is intended, but the address of another transient data element is actually indicated due to a cross purpose memory accessing error, then no triggering of the protection mechanism will occur. Similarly, authorized writing into semipermanent data with the actual address pointing within the semipermanent data area or within the transient data area will also go undetected, etc. As a consequence, the actual error which eventually triggers the hardware protection mechanism may be the first cross purpose memory accessing error, in which case the error localization and correction is simple. More often than not, however, the actual error which triggers the protection mechanism is only one of the secondary errors caused by some previous, undetected cross purpose memory accessing error. In this case the error localization is extremely difficult because the actual error may have been caused by a faultfree program operating with faulty data as has been described above. Also, in this case, the only practical error elimination scheme is a complete system restart to clear the system from all as yet undetected but latent cross purpose memory accessing errors.
Of the three possible protection mechanisms mentioned above, the third has the disadvantage that it requires extra control bits for each memory word, and thereby requires more resources than the other methods, where the protection mechanism may be more centralized. It is mainly for this reason that the other methods have been preferred, i.e. separation of memory into disjoint areas with different properties. This has, in fact, been a contributing factor to the `distributed` software realization illustrated in FIG. 6, where a single user is allocated multiple disjoint areas in the memory.
Dispersing the software belonging to, or associated with, a single user over disjoint areas in memory as illustrated in FIGS. 6 and 7 (which is forced for reliability reasons if a logical or physical separation of memory areas as described above is used) reduces the manageability and maintainability of the software, because each piece of software must now be handled separately. For manageability as well as for maintainability reasons it would be advantageous if each user software unit could be handled as a single unit also when stored in memory. The method with extra control bits for each memory word attempts a partial solution to this problem. Nevertheless it will still not give an adequate cross purpose memory access protection. FIG. 10 illustrates a simplified example of the utilization of this method for the implementation of the software associated with a single user.
The user software is shown to be implemented as a User Program Area 160 and a User Data Area 170. The User Program Area contains a number of instructions, which together form the actual user program. The starting point of the User Program Area is given by the ESS pointer (Executable Segment Start) 161. The User Data Area contains a number of data elements. These data elements have been named DE1 to DE10 in the order they have been implemented within the actual memory words. The starting point of the User Data Area is given by the DSS pointer 162 (Data Segment Start). The actual data elements DE1-DE10 in FIG. 10 may be regarded as an example of the implementation of the following logical data elements:
where HEADER, COUNTER1, etc. are the actual functional names of these data elements as used in the program. Each memory word in FIG. 10 contains a set of information bits and a set of control bits. The control bits are assumed to indicate the property (EO, ER, RW, RO, CRO) associated with the information stored in the information bits of the memory word. Hence all the memory words used to store instructions of the program are defined to be EO words (or ER where appropriate). The data words DE1-DE10 are defined as RO, CRO or RW words, depending on how the associated information is defined. The control bits may of course be used for purposes other than property indication, e.g. redundancy checks (not relevant for the present purpose).
As illustrated by FIG. 10 it is possible to locate data elements with the same properties within the same memory word, provided that a sufficient number of information bits are available to accommodate all information elements within one word. It is not possible to mix data elements with different properties within the same memory word, even when there are unused information bits available. Hence a certain amount of unused information bits is always implied.
Accessing of the memory in FIG. 10 is done by the well known Base Address +Offset technique. Thus the base address of the User Program Area is given by the ESS 161 pointer and the actual instruction undergoing execution by a relative Program OFFset (POFF) 163. Similarly, the base address of the User Data Area is given by the DSS pointer 162 and the actual accessed data element by a relative Data OFFset (DOFF) 164 given as an operand within the data accessing instructions. This technique is even directly supported by current microprocessors like the MC68000, the Z-8000 and the 8086, where base or segment registers are utilized for the base addresses with the offsets specified separately and independently of the base addresses.
Although a certain amount of hardware support is already available, this does still not solve the cross purpose memory accessing problem because :
(a) The base addresses in the base/segment registers are still calculated by the programmers and are therefore subject to programming errors. PA1 (b) The offsets themselves may be directly given in the instructions, but may also be indirectly calculated by the programmer. In the latter case the offsets are also subject to programming errors; and PA1 (c) Utilization of adequate software range checks is generally avoided because of their accompanying unacceptable performance degradation. PA1 (a) The Base Address of the Data Area itself (DSS) 162. PA1 (b) The Offset to the first element of the array (i.e. the offset to the memory word containing DE4(0)=2). PA1 (c) The Index Displacement of the actual element of the array, calculated as the actual Index times the Length of a single array element, where this length is to be taken as the number of bits reserved for a single array element.
The calculation of the base addresses is a relatively straightforward matter, because these refer to specific and unambiguously defined points in the memory of a system. FIG. 11 illustrates the well known technique of a general System Descriptor Table (SDT), where each user is assigned an entry in this table. Such a Descriptor Table is for instance forming the central Address Calculation Unit described in the Swedish patent 365 093. Each entry is assumed to contain four items of information for the purpose of base address calculation. These four items are :
______________________________________ ESS The Executable Segment Start Address ESSZ The Executable Segment Size DSS The Data Segment Start Address DSSZ The Data Segment Size ______________________________________
Use of a System Descriptor Table of the kind illustrated in FIG. 11 gives a number of advantages. Calculation of the base address for a program or a data area for a particular user is a matter of a simple readout of the appropriate information from the table entry associated with that user. Secondly, the offset value for any instruction or data element may simply be checked against the specified segment size in order to indicate overflow. Thirdly, it is possible to perform the base address calculation and range check of any offset automatically by integrating it in the hardware or the firmware of the system, thereby making it impossible for the programmers to fiddle with these address calculations. Fourthly, it is possible to make all user areas completely relocatable, even under on-line conditions, provided that no user programmable pointer relationships are used anywhere within the system. Fifthly, it is possible to assign the actual table entry associated with a particular user software unit dynamically when that software unit is loaded into the system, thereby providing a basis for pluggability of the software units. Finally, it is also possible to separate the Program Areas, the Data Areas and, in fact, the System Descriptor Table Area itself from each other by means of physically disjoint memories in order to enhance the performance of a system by the resulting ability to access the memories in parallel. The processing system of the Telecommunication System AXE designed by L.M. Ericsson in Sweden is a typical example of a system utilizing the above mentioned method in order to obtain the advantages mentioned.
A number of problems still exist, however, particularly in connection with the calculation of the offsets for the different data elements associated with a particular user. Unique data elements, i.e. data elements which occur only once, do not normally cause any problem, because their offset values may be hardcoded as operands into the instructions relative to the actual base address, provided that the hardware operates on the base address +offset principle. This is assumed to be the case with the data elements HEADER, COUNTER1 and COUNTER2 (corresponding with DE1, DE2 and DE3 in FIG. 10), where HEADER (DE1) is implemented as the first word relative to the base address DSS 162 (i.e. word offset=0), COUNTER1 is implemented as the least significant part of the second word relative to the base address DSS (i.e. word offset =1 with bit offset within the word=0 and a specified number of bits to be accessed) and COUNTER2 is implemented as the most significant part of the second word relative to the base address DSS (i.e. word offset=1 with a specified bit offset within the word&gt;0 and a specified number of bits to be accessed). Because these offsets are fixed offsets and do not change with time they may easily be hardcoded into the instructions, either as direct accesses (in the case of word accesses or when the hardware supports different access formats) or as masked accesses (for part-of-word accesses in systems where only word accesses are directly supported).
Accessing of the data element STATUS, which corresponds with the DE4 array in FIG. 10 is more complex. First of all it is normally not the entire array that is accessed but only a single element of the array. Thus it will be a single element DE4(X) which will be accessed, where X is defined as the index of the actual element. According to the definition the index may vary within the range 0-4. The actual address of any accessed element is in this case composed of the following three elements:
In FIG. 10 the DE4 array occupies five words in the memory with each array element utilizing an entire memory word. The actual data offset for STATUS (2) occupying DE4 (2) is now calculated as: EQU DOFF=2 [Offset to DE4(0)]+2 [Actual index]* 1 [length of array element]
The Length of each array element is a fixed value and can therefore be hardcoded into the instructions of the accessing program. However, because the index value is variable, the address calculation must be explicitly performed by the programmers themselves and will therefore also be subject to programming errors. In order to guard against such errors an index range check is always warranted to ensure that the used index at all times remains within its legal range (0 to 4 for DE4 in FIG. 10). Often this index range check is omitted because it will significantly degrade the performance of the system, thereby again making cross purpose memory protection errors possible.
When the length of an array element is less than a memory word as illustrated by the data elements CATEGORY and COUNTER3, which are implemented as DE6 and DE7 in FIG. 10, then certain new problems arise in the actual memory accessing. The simplest solution is, of course, to reserve an entire memory word for each array element regardless of whether the memory element actually utilizes the memory word or not. Because of hardware limitations no single part-of-word element should actually cross a physical word boundary in the memory. Thus, whenever a particular array element requires more than half of the available bits of a memory word, then an entire memory word must be reserved for each array element. However, when a particular array element requires less than half of the available bits in a memory word while, at the same time, the number of elements in the array becomes large and the number of bits required per array element is small, then reserving an entire word for each array element leads to a considerable waste of memory space, which in some cases will be completely unacceptable. The solution for such cases is to pack more than one array element in the same word. The number of bits actually reserved for each array element must be an integer fraction of the number of bits in an entire memory word in order to ensure that no array element will cross a physical word boundary. As an example, in a system with 24 bit memory words, array elements of 1, 2, 3, 4, 6, 8, and 12 bits would be possible. Hence, if a logical data element would require 7 bits, then an 8 bit array element would actually be used.
As long as the number of elements in an array is fixed, the accessing of any element in the array does not pose any great problems, provided that adequate range checking is performed at all times. However, the number of elements in arrays do vary. Normally the number of elements is increasing with time as the systems expand in order to be able to cope with new requirements. Any associated arrays must also be extended. The effect of this expansion can be devastating. The data element DE5 in FIG. 10 occupies words 8-10 in the User Data Area, i.e. the word offset to this data element, which is hardcoded as an operand into the instructions of the program, is 7. If now the DE4 array is extended by 3 more array elements, then the entire DE4 array would thereafter consist of 8 elements, i.e. DE4(0), DE4(1), DE4(2), DE4(3), DE4(4), DE4(5), DE4(6) and DE4(7). For pure address calculation reasons the new array elements have to be appended to the previous array elements, i.e. they have to occupy memory words 8, 9 and 10. However, these memory words were previously occupied by DE5. In other words, extension of an array may cause other data element to be relocated. In our example DE5 would now be relocated 3 words forward, thereby necessitating a change of the hardcoded memory offsets within the program. This change will of course ripple through all subsequent data elements. This is especially dangerous if a number of disjoint programs access the same data areas, because it will be difficult to verify that all data accesses have actually been changed. Thus the extension procedures may again form a potential cause of cross purpose memory protection errors. This problem is further complicated when multidimensional arrays are used, i.e. arrays where the element of the arrays in themselves are arrays.
One partial solution to the above problem is the way utilized within the previously mentioned AXE system, which is described in Ericsson Review No. 2, 1976, and also described in the Swedish patent 365 093.
This system recognizes that any user function may be implemented in software in the standardized way shown in FIG. 12, where a user function comprises a Program part 180, a Common Data part 182 and an Individual Data part 184.
The Program part of FIG. 12 corresponds with the User Program Area 160 in FIG. 10.
The Common Data part may be considered to contain all unique (nonreplicated) data elements in FIG. 10, i.e. DE1, DE2, DE3, DE5, DE8, DE9 and DE10.
The Individual Data part consists of an array with n elements in FIG. 12. Hence the data elements DE4, DE6 and DE7 in FIG. 10 may be considered to belong to the Individual Data part with n=5.
FIG. 13 shows the actual implementation principles of the system. For performance reasons the memory of the system is separated into three physical memories, the Program store (PS) 190 containing all programs, the Data store (DS) 192 containing all user data and the Reference store (RS) 194 containing all System Descriptor Tables.
The Reference Table in FIG. 13 corresponds directly with the System Descriptor Table in FIG. 11. Each user function is defined as a Block. The Central Processing Unit directly supports the structure with a dedicated Block Number Register 196 holding the identity of the currently active block. The contents of the Block Number Register are used to identify the actual Reference Table Entry. The three most important elements of a Reference Table Entry are shown in FIG. 13. These are:
______________________________________ PSA 198 The Program Start Address. This corresponds directly with ESS in FIGS. 10 and 11. BSA 200 The Base Start Address. This corresponds indirectly with DSS of FIGS. 10 and 11 in the manner explained below. BS 202 Block State. Administrative information. ______________________________________
Each Reference Table Entry also contains auxiliary information elements like the ESSZ and DSSZ elements in FIG. 11. These elements are not shown in FIG. 13.
The Program shown in FIG. 13 corresponds directly with the User Program Area of FIGS. 10 and 11 (disregarding the Signal Distribution Table at the beginning of the Program).
The implementation of the Data Area differs from the principle shown in FIG. 10 and FIG. 11. Instead of assembling all data elements belonging to a single user into a single User Data area in the manner shown by FIGS. 10 and 11 each individual data element is separately and individually assigned a memory location in the Data Store (DS) 192. In order to allow an easy address calculation to each single element a Data Descriptor (called a Base Address in FIG. 13 is associated with each single data element, regardless of whether the data element is a single element or an array element. All Base Addresses for data elements belonging to a particular block are assembled into the Function Block Base Address Table 204 for that particular block. The start address to this table is given by the BSA 200 address in the reference table entry corresponding with the block. Each base address contains all the relevant information associated with the corresponding data element, i.e.:
The described base address table principle has a number of advantages. Specifying all the information relevant for the calculation of an address as part of the base address makes programming simple, because the programmer will not have to perform an explicit address calculation at all. The only information required to access a particular data element is the offset to the base address associated with that data element. It is to be noted that the accessing of array elements by means of a simple offset is only possible when it is indicated within the base address itself that an element is an array element and when, furthermore, the index to the actual array element to be accessed is given by a predefined special purpose process register within the CPU. In FIG. 13 this special purpose process register is denoted as the Pointer Register 206 and is used to identify one instance of the Individual Data shown in FIG. 12. By designing the CPU so that the actual offset is always given directly as an operand within the machine instructions (corresponding with the OP1 84 or OP2 86 parts of a machine instruction in FIG. 3) it is possible to simplify the programming considerably. Any unique data element within either the Common Data or within one instance of the Individual Data may now be directly accessed by means of its fixed, hardcoded offset value. Provided that the index to the actual instance of the Individual Data and the base address itself are checked, then cross purpose memory accessing errors can be completely eliminated as far as these unique data elements are concerned.
Unfortunately both single- and multidimensional arrays may still exist within both Common Individual Data. For these array elements the addressing still has to be explicitly specified with associated explicit address checks. This case is still subject to the previously mentioned drawbacks with the associated possibility for cross purpose memory accessing errors still in existence.
One of the big advantages of a system designed according to the principles illustrated in FIG. 12 as compared to a conventional system designed according to the principles of FIG. 5 that the data elements belonging to a particular user only accessed from the program part belonging to that same user. This is the reason why each particular user may have its own unique base address table (=the Function Block Base Address Table 204 in FIG. 13), which is only accessible by the program part associated with that particular user. This considerably simplifies the maintainability, manageability and enhancability of the software, because every user function may now be handled as a single entity. It is still not possible to handle any part of the user functions (i.e. program part, common data part and individual data part) separately because these are logically tied into each other.
Secondly, the reliability is also directed enhanced, because it is now possible to introduce a hardware protection against a particular user accessing the base address table belonging to a different user, thereby preventing all accesses of data elements belonging to a particular user by other users before that access can take place. If no multidimensional array elements exist it is even possible to extend this hardware supported protection to the level of a single data element in FIG. 13 (i.e. C1, C2, X, Y). There is now no need for separate access right protection associated with a particular memory word (by means of extra control bits in addition to the information bits) or associated with a particular memory area (by means of limit specifying register or similar) as previously described. This is the reason why the access right indication may be part of the base address itself.
An arrangement according to FIG. 13 requires the supporting processors to be specially designed in order to achieve efficient implementation. This arrangement cannot therefore be efficiently supported by presently available microprocessors, because these operate on, and efficiently support, the general base address +explicitly indicated offset principle illustrated in FIG. 10. On the other hand, a specially designed processor cannot efficiently support an implementation according to FIG. 10. In neither case are multidimensional arrays efficiently and reliably supported, because they must always be explicitly programmed.
With an arrangement according to the invention the above described disadvantages can be completely eliminated while at the same time being able to use one of the commercially available microprocessors.